NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/657

Internet Message Format | 1996-08-06 | 1.7 KB

Path: lyra.csx.cam.ac.uk!jkb
From: [e-mail] (James Bonfield)
Newsgroups: comp.std.c
Subject: Re: Restrictions on qsort compare function?
Date: 27 Mar 1996 09:40:00 GMT
Organization: MRC Laboratory of Molecular Biology, Cambridge UK
Message-ID: <4jb2dg$[e-mail]>
References: <mjs.827419998@hubcap> <mjs.827424727@hubcap> <[e-mail]>
NNTP-Posting-Host: alf2.mrc-lmb.cam.ac.uk

In article <[e-mail]> [e-mail] (Mark Brader) writes:
>Incidentally, I have encountered code where the comparison function for
>qsort() actually WAS specified with a return expression like *a < *b that
>produced 0 when it should have produced -1.  The interesting part is that,
>on the particular machine the programmer had been using, the sort worked
>correctly.  Evidently this particular qsort() implementation only tested
>whether the comparison function returned a positive value or not.

Indeed in our bugged code this was the case for SunOS 4 and SunOS 5. Irix 5.3
also sorted correctly _most_ of the time (and crashed other times). This all
strikes me as somewhat odd. In contrast to this DEC OSF/1 3.0 gave the
expected not-sorted-too-well result. The OSF system also arrived at this
result with far fewer comparisons. It also arrives at the correct result with
far fewer comparisons than other systems when testing them all with a valid
sort comparison function. My guess is that they don't use quicksort (or at
least for small number of itmes) :-) Which, of course, is perfectly compliant.

    James
--
James Bonfield ([e-mail])   Tel: [phone]   Fax: [phone]
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.